متدولوژی اسکرام در سال 1986 در کشور ژاپن توسط Hirotaka Takeuchi و Ikujiro Nonaka برای اولین بار اختراع شد. اسکرام در دهه 90 میلادی توسط Ken Schwober و Jeff Stherland توسعه داده شد و به عنوان یک متدولوژی رسمی جهت تولید محصولات نرم افزاری شناخته و به کار گرفته شد.
اسپرینت هسته اصلی اسکرام را اسپرینت ها تشکیل می دهند. در متدولوژی های تکرار شونده(iterative) دوره های زمانی تکراری(iteration) وجود دارد که در این دوره ها به تدریج محصول کامل می گردد. بدین صورت که در تولید یک محصول، تعدادی تکرار در نظر گرفته می شود که در پایان دوره زمانی هر تکرار، یک محصول قابل ارائه وجود دارد. به این دوره های زمانی تکرار شونده در اسکرام اسپرینت(sprint) می گویند. در پایان هر اسپرینت، محصول کامل تر شده و در نهایت محصول نهایی تولید می گردد. هر اسپرینت دارای تعریفی است که در آن باید مشخص شده باشد که چه چیزی قرار است ساخته شود، نیازمندی ها، راهنمای ساخت و محصول خروجی نیز باید مشخص باشند.
مجموعه نیازمندی های عملیاتی و غیر عملیاتی(Functional and NonFunctional Requirements) پروژه، که مستند شده است را backlog گویند. مجموعه نیازمندی هایی که در هر اسپرینت باید تمام شوند sprint Backlog نامیده می شود. هر sprintcycle تا زمانی ادامه پیدا می کند که محصول آماده release باشد. بعد از release محصول ممکن است صاحب پروژه نیازمندی های جدیدی به پروژه اضافه نماید که به آن ها Product Backlog گویند.
مدت زمان هر اسپرینت بستگی به نوع پروژه دارد. این مدت زمان می تواند از یک هفته تا یک ماه متغیر باشد. هر اسپرینت باید دقیقا سر وقت به اتمام برسد و اگر به هر دلیلی در پایان اسپرینت محصول آماده نبود باید نیازمندی های sprint backlog به product backlog منتقل شوند.
در ابتدا و در هنگام شروع اسپرینت، جلسه ای با حضور تمام اعضای تیم تشکیل می شود و به همه افراد هدف نهایی اسپرینت و وظایف هریک از اعضای تیم شرح داده می شود.
وظایف مشخص شده در هر اسپرینت شامل سه جنبه است:
Transparency : تمامی جنبه های فرایند برای همه اعضای تیم(مشتری و تیم برنامه نویس) باید مشخص و واضح باشد.
: Inception اگر در هر مرحله، فرایند دچار انحراف شد، باید انحراف سریع تشخیص داده شود.
Adaption : انحراف های شناسایی شده، در کم ترین زمان ممکن باید تعدیل شوند.
در هر اسپرینت، جلسه ای به صورت روزانه با حضور اعضای تیم (تیم تولید و ذینفعان) انجام می شود تا پیشرفت های پروژه بررسی گردد. در این جلسات باید به سه پرسش زیر پاسخ داده شود:
چه پیشرفت هایی حاصل شده است؟
چه موفقیت هایی در اسپرینت بعدی حاصل می گردد؟
چه موانعی برسر راه ادامه کار وجود دارد؟
در انتهای هر اسپرینت جلسه ای برگزار می شود تا محصول نهایی به ذینفع یا ذینفعان نشان داده شود و نتیجه نهایی کار بررسی گردد.
نقش های اسکرام (scrum roles)
اسکرام مستر(scrum master) : رهبر اسکرام وظیفه دارد تا تمامی اعضای تیم را هدایت و راهنمایی نماید تا هیچ یک از اعضای تیم از چارچوب و قوانین اسکرام خارج نشوند. رهبر اسکرام نقش مدیر را ندارد بلکه تنها وظیفه رهبری تیم را بر عهده دارد تا با رفع مشکلات و موانع پیش رو (در صورتی که اعضای تیم قادر به رفع موانع نباشند) ، اجرای اسکرام را بهبود بخشد.
نماینده صاحب پروژه و یا ذینفع(product owner) : صاحب پروژه با اعلام دقیق نیازمندی های خود به تیم تولید، با راهبر اسکرام و تیم تولید همکاری می نماید. صاحب پروژه باید به سوالات تیم پاسخ داده و همواره در دسترس باشد.
تیم تولید و توسعه نرم افزار(development team) :افراد این تیم در چارچوب قوانین اسکرام، به تولید آن چه که صاحب پروژه درخواست کرده است، می پردازند. تعداد اعضای تیم تولید نه باید آن قدر کم باشد که همکاری گروهی و کار تیمی بی معنا شود و نه آن قدر زیاد باشد که هماهنگی بین اعضای تیم تبدیل به امری دشوار و وقت گیر گردد. تعداد اعضای تیم تولید، بستگی به پروژه دارد اما معمولا 6 تا 9 نفر اعضای این تیم را تشکیل می دهند.
هدف اسکرام جلوگیری از شکست های معمول در حین فرایند تولید و توسعه است. بوسیله اسکرام می توان از حداکثر توان و خلاقیت تیم تولید بهره برد. این متدولوژی در تعداد زیادی پروژه در سراسر دنیا توسط شرکت های مختلف مورد استفاده قرار گرفته و موفق بوده است.
یکی از این سوالات تکراری” ربط اسکرام و " Agileبا یکدیگر می باشد .
به طور خلاصه می توان گفت Agile : یک تفکر در زمینه توسعه نرم افزار می باشد و اسکرام یک روش برای پیاده سازی این تفکر در پروژه های توسعه نرم افزار می باشد . برای واضح تر شدن مطلب باید تعریفی از هر دو مقوله داشته باشیم :
Agileدر کل چیزی نیست جز 4 ارزش . یعنی در کل Agile فقط شامل این ارزش ها می باشد :
افراد و تعاملات بالاتر از فرآیندها و ابزارها نرم افزار کارا بالاتر از مستند سازی جامع همکاری مشتری بالاتر از قرارداد کار جوابگویی به تغییرات بالاتر از پیروی یک طرح
(نقل شده از بیانیه توسعه چابک)
همانطور که بیان شد اینها ارزش های Agile می باشند یعنی مواردی که بر شمرده شد ارزشهایی می باشند که ما در محیط چابک (Agile) باید داشته باشیم . یعنی در یک محیط چابک افراد و نیروی کار و تعاملات بین آنها مهمتر از تکنولوژی و پروسه کاری می باشند یا هدف در یک محیط چابک توسعه یک نرم افزار کارا ( نرم افزاری که مسئله و یا Problem مشتری را حل و یا آسانتر نماید) می باشد یا همکاری مشتری در یک محیط چابک بسیار با ارزشتر از یک قرار داد نوشته شده که تقریبا در آخر کار 90% تغییر می کند می باشد و یا جوابگویی به تغییرات و انجام و کنترل این تغییرات جزو یکی دیگر از ارزشهای مورد نظر تفکر Agile می باشد .
ولی این ارزش ها در عمل بسیار مشکل خواهند بود برای این منظور در تفکر Agile علاوه بر ارزش ها , دوازده اصل معرفی شده است . این دوازده اصل برای دست یابی و حفظ و حراست از ارزش های Agile در محیط های چابک می باشند :
- 1بالاترین اولویت ما رضایت مشتری از طریق تحویل به موقع و مداوم نرم افزار ارزشمند می باشد.
- 2پذیرائی از نیازهای در حال تغییر , حتی آن هایی که در اواخر توسعه پدید آور می شوند. فرآیند های چابک تغییرات را جهت رقابت بر سر مشتری مهار و کنترل می نمایند
- 3تحویل نرم افزار کارکننده غالبا از چند هفته تا چند ماه یک بار انجام می شود که زمانبندی کوتاه تر ترجیح داده می شود
- 4تاجران و توسعه دهندگان باید هر روزه در طول پروژه با هم کار کنند.
- 5پروژه ها را بر روی افراد با انگیزه بنا کنید. محیط لازم را به آنها بدهید و از نیازهای آن ها پشتیبانی نمایید وبه آنها اعتماد نمایید تا کارها را انجام بدهند.
- 6کارآمدترین و موثرترین روش برای انتقال و رساندن اطلاعات به تیم توسعه , گفتگوی چهره به چهره و رودرو می باشد.
- 7نرم افزار کارکننده اصلی ترین معیار پیشرفت می باشد فرآیند های چابک توسعه پایدار را ترویج می دهند.
- 8حامیان مالی , توسعه دهندگان و کاربران باید قادر به حفظ سرعت پیشرفت ثابتی براى يک مدت نامحدود باشند.
- 9توجه مداوم به برتری فنی و طراحی خوب باعث افزایش چابکی می شود.
- 10اصل سادگی ضروری می باشد.
- 11بهترین معماری ها , نیاز مندی ها و طراحی ها از تیم های خود سازمانده پدید آور می شود.
- 12در فواصل منظم , تیم برچگونگی موثرتر شدن تامل وتفکر می نماید و سپس تیم رفتار خود را بر اساس بازتاب این تفکر تنظیم و هم سو می نماید .
(نقل شده از اصول توسعه چابک)
اگر بادقت به ارزش ها و اصول توسعه Agile توجه نموده باشید , خواهید دانست که در اصل این اصول برای دستیابی به این ارزش ها می باشند . یعنی محققان برای دستیابی به ارزش های Agile چند اصل را معرفی کرده اند که در صورت به کار بستن این اصول خواهیم توانست به ارزشهای مد نظر Agile برسیم و رسید ن به ارزش های Agile مساوی با دستیابی به ارزش های والای هرسازمانی خواهد بود . برای مثال اگر سازمانی بتواند ارزش “افراد و تعاملات بالاتر از فرآیندها و ابزارها ” را در سازمان نهادینه نماید , همانا به اهداف اصلی سازمان که شامل : نیروی کار باانگیزه , بهروری بالا , کیفیت بهتر و… دست خواهد یافت .
در تفکر Agile گذشته از این که 4 ارزش و 12 اصل برای این تفکر معرفی شده است ولی راه عملی برای دست یافتن به این ارزش ها و یا اصول ارائه نگردیده است . مثلا در اصل 6 داریم : “کارآمدترین و موثرترین روش برای انتقال و رساندن اطلاعات به تیم توسعه , گفتگوی چهره به چهره و رودرو می باشد.” ولی در عمل راهی پیشنهاد نشده است و بحث عملیاتی و عملی به اجرا کننده تفکر Agile در سازمان (نسبت به متر های سازمان مربوطه ) واگذار شده است .
به عبارت ساده تر , شما که می خواهید (چابک) Agile شوید باید این دوازده اصل را رعایت نمایید و در عمل انجام بدهید ولی نوع انجام این روش مهم نیست . شما هر طوری که دوست دارید و یا با مترهای سازمان شما جور در خواهد آمد این اصول را انجام بدهید ; ولی آیا ما مرد آن هستیم که خودمان روش هایی برای انجام این اصول تعریف نماییم ؟ بدلیل اینکه ما مرد اینکار نیستیم دوست عزیز ken schwaber لطفی کردند و متد اسکرام را برای ما معرفی کردند .
در اصلاح Scrum یک Practice یا روش عملی برای پیاده سازی و انجام اصول و ارزش های Agile در پروژه های توسعه نرم افزار می باشد . به عبارت ساده تر اسکرام یک پکیج از روش های آماده می باشد که در صورت انجام این روش ها در پروژه ها مان به اصول و ارزش های Agile دست خواهیم یافت .
مثلا در اسکرام داریم که در اول و یا آخر هر روز کاری باید Stand-Up Meeting انجام شود . همانطور که توجه دارید این یک تجویز عملی است و می گوید باید انجام بدهید (البته با کیفیت و کمیت هایی که قبلا گفته شده است) . اما با انجام این تجویز اسکرام , ما در اصل به ارزش “افراد و تعاملات” و اصل 5 اصول توسعه چابک نزدیکتر خواهیم شد . و کم کم و بعدی از مدتی خواهیم دید که چابک شده ایم .
اما مشکلی که وجود دارد این است که Scrum بر پایه ایده آل ها و یا به عبارت ساده تر با متر های ایده آل سازمان ها در کشورهای پیشرفته جهان ایجاد شده است و شاید این مترها برای ما کمی مناسب نباشد (البته نه زیاد) . پس می توانیم اسکرام را برای سازمان و یا تیم با مترهای مناسب سازمان خودمان بومی سازی نماییم (و هیچ مشکلی نیست و کمی نیاز به سعی و خطا خواهد داشت ( .
البته برای انجام اصول Agile روش هایی به جز Scrum مانند XP , Crystal و… وجود دارند که توضیح این متد ها در حیطه این مقاله نمی گنجد.
یکی از سوالات اصلی که در هنگام سوئیچ از روش های قدیمی به Scrum با آن مواجه می شویم Incremental بودن و یا Iterative بودن اسکرام است . به عبارت دیگر ما قرار است به کدامین روش کار کنیم ؟Incrementalیا Iterative
هر دو روش دقیقا معکوس یک دیگر عمل می کنند . در روش Incremental هدف توسعه یک محصول است اما تکه تکه . به عبارت دیگر ما آخر کار را به صورت قطعی می دانیم پس نسبت به دانش اولیه و کاملمان , در حال تکمیل قسمتی از محصول به صورت 100% و کامل هستیم . در متد Incremental در در هر مرحله قسمتی (تکه ای ) از کار به صورت کامل تمام شده است . یعنی در مرحله دوم دیگر نیاز نیست ما بر روی قسمت قبل دوباره کار کنیم زیرا که در مرحله قبل تمام شده است . این نوع متد نیازمند یک دید کلی و کامل از نتیجه نهایی می باشد . یعنی بدون طراحی Up-front قبل از شروع به پیاده سازی چنین متدی امکان پذیر نمی باشد .
ولی در متد دوم یا همان Iterative شاهد این هستیم که در هر تکرار کل کار شاهد دگرگونی می باشد . یعنی ما در هر تکرار بر روی کل کار کار کرده ایم و در آخر تکرار کل کار آماده است . این نوع متد وابسته به خروجی تکرار قبلی است . به عبارت ساده تر در اول کار ما فقط می خواهیم عکس یک سولوشن ارائه دهیم ولی طرح نهایی در ذهنمان وجود ندارد یعنی دانشمان کامل نیست. هر مر حله ای که به جلو می رویم یاد می گیریم و بر اساس یادگیری ها مرحله بعدی را شروع می کنیم . این همان فید بک و Review هایی هست که در اسکرام انجام می شود .
خوب شاید الان بتوانید بگویید که اسکرام بر پایه کدام روش می باشد ؟ بله , اسکرام ترکیبی از هر دو روش می باشد . به نظر می رسد متوجه شده باشید که هر دو روش یک سری معایب و مزایای بزرگ دارند :
در روش Incremental ما بخشی از محصول را به صورت کامل تمام می کنیم (مزیت) ولی این تمام کردن نیازمند یک دانش کامل و فراگیر نسبت به کل محصول است که این محصول جز با طراحی های Up-front امکان پذیر نخواهد بود (عیب) (قابل ذکر است که عیب طراحی Up-front این است که در فاز شروعی پروژه زمانی زیادی برای اینگونه طراحی ها باید صرف شود که جز تلف کردن وقت چیزی نیست ) . اما در روش Iterative ما نیازی به طراحی Up-front نخواهیم داشت زیرا رفته رفته طراحی میکنیم که اصلاحا به این نوع طراحی Just-In-time-Design اطلاق می شود . ولی در اینگونه طراحی می توانیم در دام کارهای 95% بیفتیم , شاید دیده باشید که پروژه در دو ماه به 95% می رسد ولی 5% پروژه 4 ماه طول می کشد که این همان دام 95% است که هیچ وقت تمام نمی شود.
اسکرام برای اینکه بتواند روش کاملی باشد از هر دو روش بهره جسته است .
Sprint های یک پروژه همان Iterative های ما می باشند و انجام دادن Feature های داخل هر اسپرینت Incremental ما خواهند بود . به عبارت سادتر در داخل یک Iterative که همان اسپرینت ما می باشد ما شاهد Incremental خواهیم بود .
2 نکته اساسی از نوشته های بالا قابل استنباط خواهد بود که هدف من از نگارش این مقاله فقط تبیین اهمیت این مطالب بوده است و نه ارائه یک سری تعریف کلاسیک :
Featureهای داخل هر اسپرینت زمانی که توسط یک نفر از اعضای تیم برای پیاده سازی انتخاب می شوند باید به صورت Incremental کار بشوند . یعنی اینکه باید تمام شود یعنی ویژگی های Done شدن را پیدا کند و کنار گذاشته شود و نه اینکه چند روزی کار شود بعد Stand-By و کار بروی ویژگی دیگر و بعد سوییچ به ویژگی قبلی و چند روزی دوباره کار و بعد دوباره Stand-By . برنامه نویس باید وظایف خود را در قبال ویژگی تمام کند و بلافاصله تست های لازم بر روی ویژگی باید انجام شود و خلاصه هر کاری که لازم است که این ویژگی Done شود باید پی در پی و بدون وقفه انجام شود تا سنت حسنه Incremental به جا آورده شود .
Sprint ها روح Scrum هستند . ما Iterative کار می کنیم تا یاد بگریم و نه اینکه زود به زود یک سری ویژگی به درد نخور تحویل مشتری بدهیم . ما برآیند یک اسپرینت را تحویل مشتری می دهیم و همراه مشتری اسپرینت و برآیند اسپرینت را Review می کنیم تا یاد بگریم . یاد گیری منظور , اشتباهات نیست . بلکه یاد می گیریم که چگونه یک محصول با ارزش برای مشتری ارائه بدهیم . Mike Cohn یک اصلاح با ارزش دارد : Get Feedback , Learn and Adapt . این کاملا یعنی روح اسکرام .
اسکرام واقعا زیباست . ما Incremental کار می کنیم که بتوانیم یک سری ویژگی های محصول را به صورت کامل (Done شده) در آخر اسپرینت برای Review به مشتری ارائه بدهیم Iterative کار می کنیم که بتوانیم Feedback های مشتری را دریافت کنیم (Get Feedback) ودر مورد محصول بیشتر یاد بگریم (Learn) منظور از یادگیری این است که محصول چگونه باید توسعه داده شود که برای مشتری هایمان با ارزش باشد و یادگیری هایمان را در Design اسپرینت های بعدی به کار می گیریم (Adapt) .
در آخر می توانم عرض کنم که من اصلا با بومی سازی اسکرام برای سازمان مخالف نیستم و بلکه بیشتر توصیه می کنم ولی دقت داشته باشید که در طی بومی سازی , روح اسکرام و Agile را از بین نبرید .
در اسکرام هر پروژه به تعدادی اسپرینت معمولاً دو هفته‌ای، هر اسپرینت به تعداد Backlog Item یا PBI و هر PBI به تعداد Task یا SBT تقسیم می‌شود. هر PBII نمایانگر یکی از سناریوهای مشتری مثل «مدیریت کاربران» یا «پرداخت وام» است و معمولاً پیاده‌سازی آن ۲ تا ۳ روز طول می‌کشد. هر SBT هم معمولاً ۴ تا ۶ ساعت زمان می‌برد.
وحید صمدیان
زمانی که کد می‌نویسید فرض کنید شخصی که قرار است در آینده از کدهای شما نگهداری کند یک دیوانه‌ی زنجیری است که آدرس خانه‌ی شما را می‌داند. 
